High-efficiency service chaining with agentless service nodes

ABSTRACT

An example method for distributed service chaining is provided and includes receiving a packet belonging to a service chain in a distributed virtual switch (DVS) network environment, the packet includes a network service header (NSH) indicating a service path identifier identifying the service chain. The packet is provided to a virtual Ethernet module (VEM) connected to an agentless service node (SN) providing an edge service such as a server load balancer (SLB). The VEM associates a service path identifier corresponding to the service chain with a local identifier such as a virtual local area network (VLAN). The agentless SN returns the packet to the VEM for forwarding on the VLAN. Because the VLAN corresponds exactly to the service path and service chain, the packet is forwarded directly to the next node in the service chain. This can enable agentless SNs to efficiently provide a service chain for network traffic.

CROSS-REFERENCE TO RELATED APPLICATIONS

Co-pending U.S. application Ser. No. 13/872,008, filed on Apr. 26, 2013,entitled “ARCHITECTURE FOR AGENTLESS SERVICE INSERTION,” and Co-pendingU.S. application Ser. No. 14/020,649, filed on Sep. 6, 2013, entitled“DISTRIBUTED SERVICE CHAINING IN A NETWORK ENVIRONMENT” are incorporatedherein by reference.

TECHNICAL FIELD

This disclosure relates in general to the field of communications and,more particularly, to high-efficiency service chaining with agentlessservice nodes.

BACKGROUND

Data centers are increasingly used by enterprises for effectivecollaboration and interaction and to store data and resources. A typicaldata center network contains myriad network elements, including hosts,load balancers, routers, switches, etc. The network connecting thenetwork elements provides secure user access to data center services andan infrastructure for deployment, interconnection, and aggregation ofshared resource as required, including applications, hosts, appliances,and storage. Improving operational efficiency and optimizing utilizationof resources in data centers are some of the challenges facing datacenter managers. Data center managers want a resilient infrastructurethat consistently supports diverse applications and services andprotects the applications and services against disruptions. A properlyplanned and operating data center network provides application and dataintegrity and optimizes application availability and performance.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts, in which:

FIG. 1 is a block diagram illustrating a communication system fordistributed service chaining in a network environment;

FIG. 2 is a block diagram illustrating example details of an embodimentof the communication system;

FIG. 3 is a block diagram illustrating other example details of anembodiment of the communication system;

FIG. 4 is a block diagram illustrating yet other example details of anembodiment of the communication system;

FIG. 5 is a block diagram illustrating yet other example details of anembodiment of the communication system;

FIG. 6 is a block diagram illustrating yet other example details of anembodiment of the communication system;

FIG. 7 is a flow diagram illustrating example operations that may beassociated with an embodiment of the communication system;

FIG. 8 is a flow diagram illustrating other example operations that maybe associated with an embodiment of the communication system;

FIG. 9 is a block diagram illustrating yet other example details of anembodiment of the communication system;

FIG. 10 is a block diagram illustrating yet other example details of anembodiment of the communication system; and

FIG. 11 is a flow diagram illustrating yet other example details of anembodiment of the communication system.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

An example method for distributed service chaining in a networkenvironment is provided and includes receiving a packet belonging to aservice chain in a distributed virtual switch (DVS) network environment,where the packet includes a network service header (NSH) indicating aservice path identifier identifying the service chain and a location ofthe packet on the service chain, evaluating a service forwarding tableto determine a next service node based on the service path identifierand the location, with a plurality of different forwarding tablesdistributed across the DVS at a corresponding plurality of virtualEthernet Modules (VEMs) associated with respective service nodes in theservice chain, and forwarding the packet to the next service node, withsubstantially all services in the service chain provided sequentially tothe packet in a single service loop on a service overlay.

Example Embodiments

Turning to FIG. 1, FIG. 1 is a simplified block diagram illustrating acommunication system 10 for distributed service chaining in a networkenvironment in accordance with one example embodiment. FIG. 1illustrates a network 12 (generally indicated by an arrow) comprising adistributed virtual switch (DVS) 14. DVS 14 can include a servicecontroller 16. A plurality of service nodes (SN) 18 (e.g., SNs18(1)-18(5)) may provide various network services to packets entering orleaving network 12. A plurality of virtual machines (VMs) may providerespective workloads (WLs) 20 (e.g., WL 20(1)-20(5)) on DVS 14, forexample, by generating or receiving packets through DVS 14. One or morevirtual Ethernet modules (VEMs) 22 (e.g., VEMs 22(1)-22(3)) mayfacilitate packet forwarding by DVS 14. In various embodiments, DVS 14may execute in one or more hypervisors in one or more servers (or othercomputing and networking devices) in network 12. Each hypervisor may beembedded with one of VEMs 22 that can perform various data planefunctions such as advanced networking and security, switching betweendirectly attached virtual machines, and uplinking to the rest of thenetwork. Each VEM 22(1)-22(3) may include respective vPaths 24(1)-24(3)that can redirect traffic to SNs 18 before DVS 14 sends the packets intoWLs 20.

Note that although only a limited number of SNs 18, WLs 20, VEMs 22, andvPaths 24 are provided in the FIGURE for ease of illustration, anynumber of service nodes, workloads, VEMs and vPaths may be included incommunication system 10 within the broad scope of the embodiments.Moreover, the service nodes and workloads may be distributed withinnetwork 12 in any suitable configuration, with various VEMs and vPathsto appropriately steer traffic through DVS 14.

Embodiments of communication system 10 can facilitate distributedservice chaining in network 12. As used herein, the term “service chain”includes an ordered sequence of a plurality of services provided by oneor more SNs (e.g., applications, virtual machines, network appliances,and other network elements that are configured to provide one or morenetwork services) in the network. A “service” may include a feature thatperforms packet manipulations over and beyond conventional packetforwarding. Examples of services include encryption, decryption,intrusion management, firewall, load balancing, wide area network (WAN)bandwidth optimization, application acceleration, network basedapplication recognition (NBAR), cloud services routing (CSR), virtualinterfaces (VIPs), security gateway (SG), network analysis, etc. Theservice may be considered an optional function performed in a networkthat provides connectivity to a network user. The same service may beprovided by one or more SNs within the network.

According to some embodiments, a user (e.g., system administrator) canconfigure the service chain and provision it directly at an applicableworkload 20 (e.g., WL 20(1)). Service controller 16 may segment the userconfigured service chain in DVS 14. According to various embodiments,VEMs 22(1)-22(3) may generate headers for forwarding packets accordingto the configured service chain such that substantially all services inthe service chain may be provided in a single service loop irrespectiveof the number of services, with respective VEMs 22(1)-22(3) makingindependent decisions (e.g., without referring to other VEMs or othernetwork elements) about the next hop decisions in the service chainpacket forwarding. As used herein, the term “service loop” refers to apath of the packet from a starting point (e.g., WL 20(1)) throughvarious service nodes (e.g., SN 18(2), SN 18(4), SN 18(5)) of theservice chain until termination at the starting point (e.g., WL 20(1)).The service chain traffic may be steered over network 12 in a serviceoverlay 26. Note that it is not always necessary to terminate thestarting point, so that this may not necessarily be a “loop.” It isintended for “service loop” to encompass the operation in either case.

As used herein, the term “service controller” includes a process (e.g.,instance of a computer program that is executing) that can provisionservices at one or more service nodes according to preconfiguredsettings. The preconfigured settings may be provided at the servicecontroller by a user through an appropriate command line interface,graphical user interface, script, or other suitable means. The term“VEM” includes one or more network interfaces, at least some portions ofswitching hardware and associated firmware and software, and one or moreprocesses managing the one or more network interfaces to facilitatepacket switching in a switch, including a distributed virtual switch(e.g., DVS 14). VEMs may be named as service VEMs when they provideconnectivity to service nodes; and as classifier VEMs when they provideconnectivity to the workloads that function as the initial node in aservice chain. In certain embodiments, one or more VEMs may be providedin an instance of a Cisco® unified computing system (UCS) rack server.

Service overlay 26 encompasses a level of indirection, orvirtualization, allowing a packet (e.g., unit of data communicated inthe network) destined to a specific workload to be divertedtransparently (e.g., without intervention or knowledge of the workloads)to other service nodes as appropriate. Service overlay 26 includes alogical network built on top of existing network 12 (the underlay).Packets are encapsulated or tunneled to create the overlay networktopology. For example, service overlay 26 can include a suitable header(called a network service header (NSH)), with corresponding source anddestination addresses relevant to the service nodes in the servicechain.

For purposes of illustrating the techniques of communication system 10,it is important to understand the communications that may be traversingthe system shown in FIG. 1. The following foundational information maybe viewed as a basis from which the present disclosure may be properlyexplained. Such information is offered earnestly for purposes ofexplanation only and, accordingly, should not be construed in any way tolimit the broad scope of the present disclosure and its potentialapplications.

Service chaining involves steering traffic through multiple services ina specific order. The traffic may be steered through an overlay network,including an encapsulation of the packet to forward it to appropriateservice nodes. The services in the chain are typically of two types:agentful services and agentless services. Agentful services host anembedded agent owned by a network infrastructure provider to abstractthe underlying network details in inserting services. The embedded agentexposes application programming interfaces (APIs) to the services toenable interaction with the underlying (network) infrastructure forservice insertion including communication of metadata to the servicesand utilizing advanced infrastructure capabilities (e.g., offloads).Agentless services integrate with the underlying infrastructure in theirnative forms through respective network interfaces. Although agentlessservices lose the ability to utilize advanced infrastructurecapabilities, it eases integration of services. Given the benefits ofeither type of service, any service chaining architecture shoulddesirably support both types of service in a service chain. The trafficsteering mechanism executes either completely in the networkinfrastructure, or both in the network infrastructure and the agents(that execute in the respective service nodes).

Existing service insertion architectures (such as vPath) support bothagentful and agentless services. However, typical service chainingincludes either agentful services, or alternatively, agentless services;the service chains do not include both agentful and agentless servicesin the same service chain. In addition, the service chains areorchestrated in a centralized fashion in the network infrastructure. Thecentralized model of service chaining is termed hub-n-spoke orin-and-out: a network node (switch/router) intercepting and classifyingthe traffic (requiring services) acts as the hub, while the spokesextend from the central node to the services (e.g., via additionalswitches and routers on an overlay). Service chaining architecture insuch schemes are geared primarily for agentful services. Further, someservice chaining architectures require the services to participate inservice forwarding through the embedded agent. A major drawback of thehub-n-spoke service chaining scheme is performance degradation due tothe centralized nature of the architecture. Moreover, there does notexist a scheme that chains agentless and agentful services whilemaintaining the service forwarding solely in the network infrastructure.

Communication system 10 is configured to address these issues (andothers) in offering a system and method for distributed service chainingin a network environment. Embodiments of communication system 10 mayfacilitate a distributed method of service chaining that chains bothagentful and agentless services in the same service chain, withoutparticipation of services in service forwarding. Each VEM 22(1)-22(3)may serve as an originator of respective network service headers (NSHs)for service overlay 26. As used herein, the term “network serviceheader” includes a data plane header (e.g., metadata) added toframes/packets. The NSH contains information required for servicechaining, and metadata added and consumed by SNs 18 and WLs 20.(Examples of metadata include classification information used for policyenforcement and network context for forwarding post service delivery).According to embodiments of communication system 10, each NSH mayinclude a service path identifier identifying the service chain to whicha packet belongs, and a location of the packet on the service chain,which can indicate the service hop (NSH aware node to forward thepacket) on service overlay 26. The service path identifier and thelocation of the packet can comprise any suitable text, number orcombination thereof. In an example embodiment, the service pathidentifier is a 24 bit number, and the location may be specified by an 8bit number.

According to various embodiments, a user may configure (e.g., provision,arrange, organize, construct, etc.) the service chains at servicecontroller 16. Service controller 16 may discover location of servicenodes 18(1)-18(5). In some embodiments, the service chain may beprovisioned by service controller 16 in a port profile at respectivevPaths 24(1)-24(3) associated with specific workloads 20 thatinstantiate the service chains, thereby binding the service policyincluding the service chain with the network policy included in the portprofile. In other embodiments, when service chains are instantiated atclassifier VEM 22(1), associated with the initiating workload 20(2),service controller 16 may be notified of the service chaininstantiation. Service controller 16 may assign a path identifier toeach instantiated service chain. Service controller 16 may populateservice forwarding table entries indicating the next service hop forrespective service chains identified by corresponding path identifiers.Service controller 16 may program service forwarding tables atappropriate VEMs 22 based on service node discovery information.

Merely for illustrative purposes, and not as a limitation, assume aservice chain 1 provisioned at WL 20(2) as follows: WL2→SN2→SN4→SN5. Inother words, a packet originating at WL 20(2) may be steered to SN18(2), serviced accordingly, then to SN 18(4), then to SN 18(5), andfinally returned to WL 20(2). VEM 22(1) may generate an NSH includingthe Internet Protocol (IP) or Media Access Control (MAC) address of VEM22(1) at which WL 20(2) is located as a source address, and an IP/MACaddress of SN 18(2) as the next service hop. Destination VEM 22(2), atwhich SN 18(2) is located may inspect the NSH and take suitable actionsdepending on whether SN 18(2) includes an agent (e.g., agentful) or doesnot include an agent (e.g., agentless). If SN 18(2) is agentless, VEM22(2) may cache the information included in the NSH in a flow table. IfSN 18(2) is agentful, the packet may be forwarded to the agent asappropriate.

According to various embodiments, after the packet is suitably servicedat SN 18(2), VEM 22(2) may intercept the packet and lookup the nextservice hop. The NSH may be updated to indicate the next service hop asSN 18(4) (rather than WL 20(2), for example). The packet may beforwarded on service overlay 26 to the next service hop, where VEM 22(3)may intercept the packet, and proceed appropriately.

Embodiments of communication system 10 may decentralize the serviceforwarding decisions, with each VEM 22 making appropriate next servicehop decisions. Embodiments of communication system may facilitatetermination or re-origination (as appropriate) of service overlay 26,with seamless integration of agentful and agentless services. Any kindof network (e.g., enterprise, service provider, etc.) may implementembodiments of communication system 10 as appropriate.

Further, the service forwarding decision at any of VEMs 22(1)-22(3) maybe limited to the next-hop of the service chain, rather than all hops ofthe service chain. For example, the next service hop decision at theclassifier VEM (e.g., VEM 22(1)) may determine the first SN (e.g., SN18(2)) in the service chain and may send the traffic on service overlay26 to the first SN (e.g., SN 18(2)). The NSH may be written to indicatethe source as VEM 22(1) and next service hop as SN 18(2): <overlay:source=VEM1), destination=SN2>. The service VEM (e.g., VEM 22(2)) at SN18(2) may simply allow the traffic on service overlay 26 to pass throughto SN 18(2).

After the service is delivered at the SN (e.g., SN 18(2)), the SN (e.g.,SN 18(2)) may simply send the serviced traffic back on service overlay26 to where traffic came from (e.g., WL 20(2), or VEM 22(1)). Forexample, SN 18(2) may write the NSH to indicate the source as SN 18(2)and destination as VEM 22(1): <overlay: source=SN2, destination=VEM1>.The return traffic may be intercepted by the service VEM (e.g., VEM22(2)) next (or closest) to the SN (e.g., SN 18(2)). The interceptingservice VEM (e.g., VEM 22(2)) may make the service forwarding decision,determining the next SN (e.g., SN 18(4)) in the service chain andre-originating the NSH to the next SN (e.g., SN 18(4)). The NSH may berewritten to indicate the source as VEM 22(2) and destination as SN18(4): <overlay: source=VEM2, destination=SN4>.

The process of service forwarding can continue from VEMs 22 to SNs 18until all SNs in the service chain deliver services. The forwardingdecision may be based on the presence or absence of an agent at SN 18.For example, assume merely for example purposes and not as a limitation,that SN 18(4) is agentless, VEM 22(3) may notice that NSH indicates adestination of SN 18(4), which is agentless. VEM 22(3) may terminateservice overlay 26 and perform translation to send the traffic to SN18(4). After SN 18(4) delivers the service, it may simply send theoriginal payload packet out, which may be received by VEM 22(3) fortranslation back onto service overlay 26. VEM 22(3) may intercept SN18(4)'s traffic and determine the next service hop as SN 18(5) (which,for example purposes, may be agentful and on the same VEM as SN 18(4)).VEM 22(3) may re-originate NSH to SN 18(5): <overlay: source=VEM3,destination=SN5>. After the service is applied, SN 18(5) may simplyre-originate the NSH back to VEM 22(3): <overlay: source=SN5,destination=VEM3>.

The service VEM (e.g., VEM 22(3)) intercepting the return traffic fromthe last SN (e.g., SN 18(5)) in the service chain may determine the endof service chain. If the last VEM (e.g., VEM 22(3)) is capable offorwarding the payload traffic, it may simply forward it on the underlaynetwork (e.g., network 12). If on the other hand, the payload trafficcan only be forwarded by classifier VEM (e.g., VEM 22(1)), the NSH maybe re-originated by the last VEM (e.g., VEM 22(3)) back to theclassifier VEM (e.g., VEM 22(1)). VEM 22(1) may receive the servicedpacket on service overlay 26 and may determine that all services on theservice chain are delivered. VEM 22(1) may forward the original payloadpacket, serviced by the service chain, natively or on the underlaynetwork (e.g., network 12), as appropriate.

In some embodiments, for example, as in a service provider networkenvironment that represents a non-homogeneous environment, the networkinfrastructure, including DVS 14 may be owned and operated by theprovider; WLs 20 may belong to the tenants of the provider; and SNs 18may be hosted by the provider on behalf of the tenant or hosted by thetenants themselves, or by other third parties. In some embodiments, forexample, wherein the service provider hosts SNs 18 on behalf of thetenant, NSH of service overlay 26 may use the IP/MAC addresses of VEMs22 and SNs 18 for source and destination addresses.

In some other embodiments, for example wherein the tenants host SNs 18,traffic over service overlay 26 may be forwarded in two hops: (1)provider overlay; and (2) tenant overlay. In provider overlay,origination and termination of service overlay 26 may be implementedwithin the network infrastructure, including DVS 14 (and associated VEMs22). Hence, the end points of the provider overlay may comprise VEMs 22.For example, turning to the example of service chain 1, one of theprovider overlay hops may stretch from VEM 22(1) to VEM 22(2): <overlay:source=VEM1, destination=VEM2>. In tenant overlay, the origination mayoccur in the network infrastructure and the termination may be a localdestination. Continuing the example of service chain 1, one of thetenant overlay hops may stretch from VEM 22(2) to SN 18(2): <overlay:source=VEM2, destination=SN2>. The tenant overlay source address can belocal to respective VEMs 22 (e.g., VEM 22(2)), allowing for overcomingthe tenant and provider address domain packet forwarding issues acrossthe service provider network.

Embodiments of communication system 10 can provide a method todecentralize the service forwarding decisions across the networkinfrastructure, enabling overlays to be re-originated within the networkinfrastructure while allowing the agentful service nodes to be agnosticto service chaining. Embodiments of communication system 10 can enableservice chains that can have agentful as well as agentless services aspart of the same service chain. Embodiments of communication system 10can also provide a method for maintaining the provider and tenantaddress space separation while allowing the service chains to cross theprovider-tenant network boundary.

According to various embodiments of communication system 10, servicechains can be realized in a distributed fashion across the networkinfrastructure without a centralized bottleneck while keeping theagentful services agnostic to service forwarding decisions. Servicechains may contain both agentful and agentless services while beingagnostic to service forwarding decisions. Service chaining performancemay stay constant and may not degrade with the number of services in theservice chain. Service chains may involve services that are hosted byeither the provider or the tenant without departing from the scope ofthe embodiments, providing a ‘clean’ service chaining implementation inboth enterprise and service provider environments (among other networkenvironments).

Turning to the infrastructure of communication system 10, the networktopology can include any number of servers, virtual machines, switches(including distributed virtual switches), routers, and other nodesinter-connected to form a large and complex network. A node may be anyelectronic device, client, server, peer, service, application, or otherobject capable of sending, receiving, or forwarding information overcommunications channels in a network. Elements of FIG. 1 may be coupledto one another through one or more interfaces employing any suitableconnection (wired or wireless), which provides a viable pathway forelectronic communications. Additionally, any one or more of theseelements may be combined or removed from the architecture based onparticular configuration needs. Communication system 10 may include aconfiguration capable of TCP/IP communications for the electronictransmission or reception of data packets in a network. Communicationsystem 10 may also operate in conjunction with a User DatagramProtocol/Internet Protocol (UDP/IP) or any other suitable protocol,where appropriate and based on particular needs. In addition, gateways,routers, switches, and any other suitable nodes (physical or virtual)may be used to facilitate electronic communication between various nodesin the network.

Note that the numerical and letter designations assigned to the elementsof FIG. 1 do not connote any type of hierarchy; the designations arearbitrary and have been used for purposes of teaching only. Suchdesignations should not be construed in any way to limit theircapabilities, functionalities, or applications in the potentialenvironments that may benefit from the features of communication system10. It should be understood that communication system 10 shown in FIG. 1is simplified for ease of illustration.

The example network environment may be configured over a physicalinfrastructure that may include one or more networks and, further, maybe configured in any form including, but not limited to, local areanetworks (LANs), wireless local area networks (WLANs), VLANs,metropolitan area networks (MANs), wide area networks (WANs), VPNs,Intranet, Extranet, any other appropriate architecture or system, or anycombination thereof that facilitates communications in a network. Insome embodiments, a communication link may represent any electronic linksupporting a LAN environment such as, for example, cable, Ethernet,wireless technologies (e.g., IEEE 802.11x), ATM, fiber optics, etc. orany suitable combination thereof. In other embodiments, communicationlinks may represent a remote connection through any appropriate medium(e.g., digital subscriber lines (DSL), telephone lines, T1 lines, T3lines, wireless, satellite, fiber optics, cable, Ethernet, etc. or anycombination thereof) and/or through any additional networks such as awide area networks (e.g., the Internet).

In various embodiments, services nodes 18(1)-18(5) represent a specificfunctionality (e.g., provision of a specific service) and may beembodied in one or more physical appliances. For example, some servicesnodes (e.g., service nodes 18(4) and 18(5)) may be provided in a commonnetwork element, whereas some other service nodes (e.g., 18(1) and18(2)) may be stand-alone network elements that are configured toexclusively provide the respective specific service. Note that althoughonly five service nodes 18(1)-18(5) are illustrated in FIG. 1, anynumber of service nodes and corresponding services may be providedwithin the broad scope of the embodiments.

In various embodiments, workload 20 may be separate computing devicesrunning applications (e.g., server/client applications in client-servernetwork architecture). In other embodiments, workload 20 may be separatevirtual machines on the same or different computing devices (e.g.,server blades in a data center). In some embodiments, workload 20 mayinclude server blades configured in one or more chassis. DVS 14 mayinclude physical and virtual switches and can include any suitablenetwork element capable of receiving packets, and forwarding packetsappropriately in a network environment. Any number of workload may beactive within network 12 within the broad scope of the embodiments.

VEMs 20 can include virtual interfaces (e.g., virtual equivalent ofphysical network access ports) that maintain network configurationattributes, security, and statistics across mobility events, and may bedynamically provisioned within virtualized networks based on networkpolicies stored in DVS 14 as a result of VM provisioning operations by ahypervisor management layer. VEMs 22 may follow virtual networkinterface cards (vNICs) when VMs move from one physical server toanother. The movement can be performed while maintaining portconfiguration and state, including NetFlow, port statistics, and anySwitched Port Analyzer (SPAN) session. By virtualizing the networkaccess port with DPs 24(2)-24(6), transparent mobility of VMs acrossdifferent physical servers and different physical access-layer switcheswithin an enterprise network may be possible. vPaths 24(1)-24(3) mayprovide intelligent traffic steering (e.g., flow classification andredirection), and fast path offload for policy enforcement of flows.vPaths 24(1)-24(3) may be configured for multi-tenancy, providingtraffic steering and fast path offload on a per-tenant basis. Althoughonly three vPaths 24(1)-24(3) are illustrated in FIG. 1, any number ofvPaths may be provided within the broad scope of the embodiments ofcommunication system 10.

In one example embodiment, service controller 16 may be an applicationcoupled with a management module (e.g., virtual supervisor module (VSM))of DVS 14. In another embodiment, service controller 16 may be astand-alone application (e.g., provisioned in a suitable networkelement) separate and distinct from DVS 14 and communicating therewiththrough appropriate communication links. In some embodiments, servicecontroller 16 may be provisioned in the same local area network asworkload 20. In other embodiments, service controller 16 may beprovisioned in a different local area network separate and remote fromworkload 20. Service controller 16 may include a graphical userinterface (GUI) based controller, or a CLI based controller, or acombination thereof.

Turning to FIG. 2, FIG. 2 is a simplified block diagram illustratingexample details that may be associated with an embodiment ofcommunication system 10. An example service chain is illustrated in thefigure, starting at WL 20(2), proceeding to SN 18(2), then to SN 18(3),then to SN 18(4), then to SN 18(5), and lastly, to WL 20(5):WL2→SN2→SN3→SN4→SN5→WL5. Service controller 16 may program serviceforwarding tables 30(1)-30(3) at respective VEMs 22(1)-22(3). Eachservice forwarding table 30(1)-30(3) may include a path identifier (ID)and a next service hop information. Some SNs 18 may include an agent 32.For example, SN 18(3) may include agent 32. Note that the configurationdescribed herein is merely for example purposes, and is not intended tobe a limitation of embodiments of communication system 10.

The packet from WL 20(2) may be encapsulated with the NSH at classifierVEM 22(1) based on information in service forwarding table 30(1). Thepacket may be forwarded on service overlay 26 to the next service hop,namely SN 18(2). VEM 22(2) may decapsulate the NSH, and forward thepacket through interface 34(1) to SN 18(2), which may be agentless. SN18(2) may service the packet, and rewrite the packet header to indicatethe destination address of VEM 22(1) and send the packet out throughinterface 34(2). VEM 22(2) may intercept the packet, and re-originatethe NSH based on information in service forwarding table 30(2). Thedestination is written to be the IP/MAC address of SN 18(3). VEM 22(2)may forward the packet to SN 18(3) transparently (e.g., withoutdecapsulation of the NSH) via interface 34(3) as SN 18(3) includes agent32. After being serviced, the packet may be returned to VEM 22(2) viainterface 34(3). VEM 22(2) may intercept the packet, and re-originatethe NSH based on information in service forwarding table 30(2). Thedestination may be written to be the IP/MAC address of SN 18(4) and thepacket forwarded to VEM 22(3) on service overlay 26.

VEM 22(3) may decapsulate the packet, and forward the packet to SN 18(4)over interface 34(4). SN 18(4) may service the packet appropriately, andattempt to return it to VEM 22(1) over interface 34(5). VEM 22(3) mayintercept the packet, and re-originate the NSH based on information inservice forwarding table 30(3). The destination may be written to be theIP/MAC address of SN 18(5) and the packet forwarded to SN 18(5) overinterface 34(6). SN 18(5) may service the packet appropriately, andattempt to return it to VEM 22(1) over interface 34(7). VEM 22(3) mayintercept the packet, and re-originate the NSH based on information inservice forwarding table 30(3). In some embodiments, the destination maybe written to be the IP/MAC address of WL 20(5) and the packet forwardedto WL 20(5) over network 12, or the appropriate interface. In otherembodiments, the destination may be written to be the IP/MAC address ofclassifier VEM 22(1) and the packet forwarded to WL 20(2) on serviceoverlay 26 as appropriate.

Turning to FIG. 3, FIG. 3 is a simplified block diagram illustratingexample details that may be associated with an embodiment ofcommunication system 10. Data traffic may be communicated on underlaynetwork 12, and service traffic (e.g., packets subject to being servicedat various SNs 18) may be communicated on service overlay 26. An exampledata traffic path may comprise communication between WL 20(1) and WL20(4), and the service traffic path may comprise communication from WL20(1) to SN 18(1), to SN 18(2), to SN 18(3), and back to WL 20(1):WL1→SN1→SN2→SN3→WL1. Assume, merely for example purposes and not as alimitation that SN 18(1) and SN 18(3) are agentful, including respectiveagents 32(1) and 32(2), and SN 18(2) is agentless.

Service controller 16 may configure multiple paths (e.g., a forward pathand a return path) on each service forwarding table 30(1)-30(3). Eachpath may indicate the service path identifier that indicates (e.g.,identifies) the specific service chain, a location on the service chain,indicated by a service index, and a next service node on the servicechain. For example, at service forwarding table 30(1) on VEM 22(1), afirst path may be configured as P1: seq5: SN1, indicating service chainidentified by service path identifier P1, with a service index seq5corresponding to the location of the packet on service chain P1, and anext service node of SN 18(1) (e.g., when the packet arrives at VEM22(1) on service chain P1 with service index seq5, send it to SN 18(1)).A second path at service forwarding table 30(1) on VEM 22(1) may beconfigured as P1: seq1: end, indicating the service chain identified byservice path identifier P1, with a service index seq1 corresponding tothe end of the return service traffic path at VEM 22(1) (e.g., when thepacket arrives at VEM 22(1) on service chain P1 with service index seq1,end the service path).

At service forwarding table 30(2) on VEM 22(2), the first path may beconfigured as P1: seq5: SN1, indicating the service chain identified byservice path identifier P1, with a service index seq5 corresponding tothe location seq5 of the packet on the service chain and next servicenode of SN 18(1) (e.g., when the packet arrives at VEM 22(2) on servicechain P1 with service index seq5, send it to SN 18(1)). The second pathat service forwarding table 30(2) on VEM 22(2) may be configured as P1:seq4: SN2, indicating the service chain identified by service pathidentifier P1, with a service index seq4 corresponding to the locationseq4 of the packet on the service chain and the next service node of SN18(2) (e.g., when the packet arrives at VEM 22(2) on service chain P1with service index seq4, send it to SN 18(2)).

At service forwarding table 30(3) on VEM 22(3), the first path may beconfigured as P1: seq4: SN2, indicating the service chain identified byservice path identifier P1, with a service index seq4 corresponding tothe location seq4 of the packet on the service chain and the nextservice node of SN 18(2) (e.g., when the packet arrives at VEM 22(3) onservice chain P1 with service index seq4, send it to SN 18(2)). Thesecond path at service forwarding table 30(3) on VEM 22(3) may beconfigured as P1: seq3: SN3, indicating the service chain identified byservice path identifier P1, with a service index seq3 corresponding tothe location seq3 of the packet on the service chain and the nextservice node of SN 18(3) (e.g., when the packet arrives at VEM 22(3) onservice chain P1 with service index seq3, send it to SN 18(3)). Thethird path at service forwarding table 30(3) on VEM 22(3) may beconfigured as P1: seq1: VEM1, indicating the service chain identified byservice path identifier P1, with a service index seq1 corresponding tothe location seq1 of the packet on the service chain and the nextservice node of VEM 22(1) (e.g., when the packet arrives at VEM 22(3) onpath P1 with service index seq1, send it to VEM 22(1)).

Turning to FIG. 4, FIG. 4 is a simplified block diagram illustratingdetails of an example VEM 22 according to an embodiment of communicationsystem 10. An incoming packet 36 may include NSH 38, a transport header40, and a payload 42. A receive module 44 at VEM 22 may receive packet36. A decapsulate module 46 may decapsulate the transport header 40 andNSH 38 and inspect the contents thereof. An encapsulate module 48 maylookup service forwarding table 30 and determine the next service hop tosend packet 36. Service forwarding table 30 may be programmed by servicecontroller 16 with appropriate entries.

If packet 36 is to be sent to an agentful service node 18, for example,which includes agent 32, encapsulate module 50 may encapsulate packet 36with another NSH 38, and retain transport header 40 and payload 42 togenerate outgoing packet 56. If packet 36 is to be sent to an agentlessservice node 18, encapsulate module 50 may remove transport header 40and generate outgoing packet 56 without NSH 38. A transmit module 50 maytransmit outgoing packet 56 to appropriate SN 18. A processor 52 and amemory element 54 may facilitate the operations described herein.

Turning to FIG. 5, FIG. 5 is a simplified block diagram illustrating anexample service forwarding table entry 57 according to an embodiment ofcommunication system 10. Example service forwarding table entry 57 mayinclude a field 58 comprising the service path ID and a service index.Field 59 may include the next service node on the path identified by theservice path ID and the service index of field 58.

Turning to FIG. 6, FIG. 6 is a simplified block diagram illustrating anexample service overlay packet format according to an embodiment ofcommunication system 10. Example service overlay packet format mayinclude NSH 38, transport header 40 and payload 42. NSH 38 may comprisefour 32-bit context headers (e.g., service shared context, serviceplatform context, network shared context, and network platform context),and an additional header 60 comprising the 24 bit service pathidentifier and 8 bit service index.

Turning to FIG. 7, FIG. 7 is a simplified flow diagram illustratingexample operations 70 that may be associated with an embodiment ofcommunication system 10. At 72, service controller 16 may discoverlocations of service nodes 18 in DVS 14. At 74, when service chains areinstantiated at classifier VEMs 22 (e.g., at WLs 20), service controller16 may be notified of the service chain instantiation. At 76, servicecontroller 16 may assign respective path identifiers to each servicechain. At 78, service controller 16 may populate service forwardingtables 30 with appropriate entries. At 80, service controller 16 mayprogram (e.g., install, implement, execute, etc.) service forwardingtables 30 at respective VEMs 22 based on service node discoveryinformation.

Turning to FIG. 8, FIG. 8 is a simplified flow diagram illustratingexample operations 90 that may be associated with an embodiment ofcommunication system 10. At 92, a determination may be made at VEM 22whether incoming traffic is on service overlay 26 (for example, thedetermination may be informed by the presence or absence of NSH 38). Iftraffic is on service overlay 26, at 92, the path identifier and serviceindex information may be obtained from NSH 38. At 96, service forwardingtable 30 may be consulted to determine next service node 18 or tuple<path-identifier, service index>. At 98, a determination may be madewhether next service node 18 is local to VEM 22. If next service node 18is local to VEM 22, a determination may be made at 100 whether servicenode 18 is agentless. If service node 18 is agentless, at 102, trafficmay be forwarded natively (e.g., without NSH 38) with service headermetadata mapped to appropriate VLAN tags. If service node 18 isagentful, at 104, another NSH 38 may be imposed with appropriate pathidentifier and service index as determined from service forwarding table30. At 106, transport header 40 with appropriate source and destinationmay be imposed to forward packet to next service node 18 and thepacket/frame may be appropriately forwarded. Turning back to 98, if nextservice node 18 is not local to VEM 22, the operations may step to 104,and continue thereafter.

Turning back to 92, if the traffic is not on overlay 92, a determinationmay be made at 108 whether the traffic is from an agentless servicenode. If not, indicating that the traffic is from WL 20, at 110, thetraffic may be appropriately classified and the service path may bedetermined (e.g., service path identifier and service index identified).The operations may step to 96 and continue thereafter. On the otherhand, at 92, if the traffic is from an agentless service node, at 112,the flow may be looked up in appropriate tables and the service pathidentifier and service index may be determined. The operations may stepto 96, and continue thereafter.

FIGS. 9 and 10 are a network diagram of a modified communication system900 in which agentless SNs may optionally be configured forhigh-efficiency service chaining. Specifically, in FIG. 9, agentless SNs920, 930, and 940 are not configured for high-efficiency servicechaining. In FIG. 10, agentless SNs 1020, 1030, and 1040 are configuredfor high-efficiency service chaining according to one or more examplesof the present Specification.

The examples of FIGS. 9 and 10 are illustrated in terms of an incomingpacket 902 and 1002, respectively, by way of non-limiting example. Itwill be readily apparent that identical methods may be applied tooutgoing packets, as discussed in previous examples, to similarlyrealize high-efficiency service chaining. It will also be readilyapparent that the specific SNs described and the specific service chainare provided only as an illustration of an example method to aid readersin more easily understanding the disclosed methods.

Communication system 900 includes a plurality of VEMs 22, labeled VEM22(1)-22(5). Each VEM 22 includes a respective vPath 24, labeled vPaths24(1)-24(5). For ease of reference, vPaths 24(1)-24(5) are abbreviatedas P1-P5 respectively. Each VEM 22 may include one or more interfaces34. To facilitate discussion, both a data plane 970 and a control plane972 are explicitly shown. Communication system 900 is controlled by aservice controller 16.

By way of example, VEM1 a 22(1) has a plurality of virtual interfaces34. A workload server WL1 20(1) is coupled to virtual interface 34(1),while a second workload server WL2 20(2) is coupled to interface 34(2).VEM1 b 22(2) is communicatively coupled to a zone firewall (ZFW) 940 viavirtual interface 34(3). VEM1 c 22(3) is communicatively coupled to aweb application firewall (WAF) via virtual interface 34(4). VEM1 d iscommunicatively coupled to a server load balancer (SLB) 920 via virtualinterface 34(5). By way of example, ZFW 940 and WAF 1030 may be treatedas “out-of-path” services, meaning that they are invisible to incomingand outgoing packets, or stated differently, packets are not expresslydirected to them. Rather, packets encounter these SNs only because theseSNs are part of an SC that the packet is required to pass through beforebeing forwarded to its ultimate destination. Out-of-path devices mayinclude, for example, data packet inspection (DPI), network analysismodules (NAM), and proxies by way of non-limiting example. In contrast,SLB 920 may be “in-path,” because traffic may be specifically directedto it. For example, when an end user requests a service provided by WL120(1), the request is directed to an IP address owned by SLB 920. SLB920 may then contain logic to determine whether to direct the packet toWL1 20(1) or WL2 20(2).

In an embodiment, incoming packet 902 arrives at communication system900 via network 12 and top-of-the-rack (ToR) switch 910. Incoming packet902 first arrives at P4 on VEM1 d 22(4), which in an example sits at theedge of communication system 900. VEM 22(4) forwards incoming packet 902to SLB 920 via interface 34(5), natively by way of packet forwarding.SLB 920 is an agentless node in this example. SLB 920 examines incomingpacket 902, and determines for example that incoming packet 902 shouldbe delivered to WL1 20(1). Because SLB 920 is agentless, it is not awareof a service chain that should be applied to incoming packet 902, and sosimply modifies the incoming packet 902 for delivery to WL1 20(1), andforwards the packet to VEM1 d 22(4). The modification may involvechanging the layer-2 and layer3 headers (or MAC and IP headers) due toNetwork Address Translation (or NAT) performed on the source IP addressor the destination IP address or both. VEM1 d 22(4) simply forwards thetransformed incoming packet 902 towards WL1 20(1) which passes throughVEM1 a 22(1). The packet is not associated with any service chain atthis point.

At interface 34(1), VEM1 a 22(1), more specifically, vPath P1 on VEM1 a,may classify the incoming packet 902 to determine that incoming packet902 is subject to service chain “SC1,” which in this example includesthe sequence SLBWAFZFW. Thus, before delivering incoming packet 902 toWL1 20(1), VEM1 a 22(1) first applies service chain SC1. Incoming packet902 has already been serviced by SLB 920, so vPath P1 of VEM1 a 22(1)determines WAF 930 as the next hop and sends incoming packet 902 over tovPath P3 of VEM1 c 22(3) after encapsulating it in NSH.

As before, VEM1 c 22(3) decapsulates incoming packet 902 and based onthe service chain in NSH delivers it to the next service node—agentlessWAF 930. WAF 930 is not aware of the service chain. WAF 930 applies webapplication firewall rules to incoming packet 902 and delivers it backto interface 34(4). vPath P3 24(3) of VEM1 c 22(3) intercepts theserviced packet 902 coming on interface 34(4) and determines the servicechain the packet belongs to based on the cached information in vPath P3.vPath P3 determines the next hop for the packet from the service chainas VEM1 b 22(2). vPath P3 re-originates the NSH and sends incomingpacket 902 to P2 of VEM1 b 22(2).

vPath P2 of VEM1 b 22(2) decapsulates incoming packet 902 and based onthe service chain in NSH delivers it to next service node—agentless ZFW940 via interface 34(3). Agentless ZFW 940 is not aware of the servicechain. ZFW 940 applies zone firewall rules to incoming packet 902 andreturns it to interface 34(3). vPath P2 of VEM1 b determines the servicechain for packet 902 and from that it determines the next hop as vPathP1 of VEM1 a. vPath P2 of VEM1 b 22(2) re-originates the NSH and thensends incoming packet 902 to vPath P1 of VEM1 a 22(1).

Finally, vPath P1 of VEM1 a 22(1) decapsulates incoming packet 902,determines the service chain has ended and delivers the packet 902 toWL1 20(1) via interface 34(1). WL1 then acts on incoming packet 902.

Summarizing the path taken by incoming packet 902, it is apparent thatservice chain SC1 results in the packet pathSLB→P4→P1→P3→WAF→P3→P2→ZFW→P2→P1→WL1. Tracing only the vPaths taken byincoming packet 902, it is found that the packet path includesP4→P1→P3→P2→P1.

In FIG. 10, it is seen that a more desirable packet path isSLB→P4→P3→WAF→P3→P2→ZFW→P2→P1→WL1, or reducing the service chain to barepaths, P4→P3→P2→P1. Thus, at least one extraneous hop is saved, whichmay result in decreased latency, network congestion and increasedthroughput. It is further recognized that other network configurationsmay result in even more wasted hops. For example, if SLB 920 and WAF1030 were both hosted on VEM1 c 22(3), incoming packet 1002 would“bounce” back and forth between P1 and P3 to receive the full servicechain.

However, because SLB 920, WAF 930, and ZFW 940 are agentless, they arenot aware of service chain SC1, and they cannot convey the service chainto VEM1 d 22(4). When traffic is received by VEM1 d from SLB 920, VEM1 dtherefore has no way to know the service chain the packet belongs to andthat delivering incoming packet 1002 to WAF 930 rather than WL1 20(1)would be more efficient. The service chain the packet 902 belongs to isknown only when that packet reaches the VEM1 a 22(1).

To overcome this difficulty, modified communication system 1000includes, by way of non-limiting example, additional mapping of localidentifiers to specific service chains. In one example, these localidentifiers are virtual local area networks (VLANs). For example, givenexample service chains SC1, SC2, and SC3, the service chains may bemapped to example VLANs 10, 11, and 12 respectively. Such a mapping isconfigured on the VEM connecting to the agentless service nodes such asSLB 1020 by the service controller 16. Thus, although SLB 1020 remainsagnostic of service chains SC1, SC2, and SC3, it may still be enabled tofollow the service chains' servicing order by directing packets toappropriate VLANs.

Thus, in an embodiment, incoming packet 1002 arrives at communicationsystem 1000 via network 12 and ToR switch 910. Incoming packet 1002first arrives at VEM1 d 22(4), which in an example sits at the edge ofcommunication system 900. VEM1 d forwards incoming packet 1002 to SLB1020 via interface 34(5) and vPath P4 is not involved in this forwardingprocess. SLB 1020 is an agentless node in this example, but has beenconfigured with a VLAN ν for traffic destined to workload poolcontaining workloads WL1 20(1) and WL2 20(2). Note that VEMs may havemany VLANs. SLB 1020 may simply choose one VLAN to forward the packeton, which in this case is designated as VLAN ν. When the packet arriveson a certain VLAN at VEM1 d, P4 maps that VLAN to a service chain. Suchmapping must be provided through control plane provisioning.

SLB 1020 examines incoming packet 1002, and determines for example thatincoming packet 1002 should be delivered to WL1 20(1) via VLAN ν.Because SLB 1020 is agentless, it is not aware of a service chain thatshould be applied to incoming packet 1002, and so simply forwards packet1002 to WL1 20(1) on VLAN ν. VEM1 d 22(4) receives this packet oninterface 34(4) on VLAN ν. VEM1 d may then classify the incoming packet1002 to determine that incoming packet 1002 is subject to service chain“SC1,” which in this example includes the sequence SLB→WAF→ZFW. vPath P4of VEM1 d 22(4) then originates the NSH on incoming packet 1002 asdescribed herein, and sends incoming packet 1002 through P4 to P3 ofVEM1 c 22(3), which is the next hop on service chain SC1.

vPath P3 of VEM1 c 22(3) decapsulates incoming packet 1002 and based onthe service chain in NSH, delivers it to agentless WAF 1030. WAF 1030 isnot aware of the service chain. WAF 1030 applies web applicationfirewall rules to incoming packet 1002 and delivers it back to interface34(4) for forwarding. vPath P3 of VEM1 c 22(3) re-originates the NSH andsends incoming packet 1002 via path P3 to P2 of VEM1 b 22(2), which isthe next hop on service chain SC1.

vPath P2 of VEM1 b 22(2) decapsulates incoming packet 1002 and based onthe service chain in NSH, delivers it to agentless ZFW 940 via interface34(3). Agentless ZFW 940 is not aware of the service. ZFW 940 applieszone firewall rules to incoming packet 1002 and returns it to interface34(3) for forwarding. vPath P2 of VEM1 b 22(2) re-originates the NSH andthen sends incoming packet 1002 via path P2 to path P1 of VEM1 a 22(1),which is the next hop on service chain SC1.

Finally, VEM1 a 22(1) decapsulates incoming packet 1002, determines thatthe service chain SC1 has ended based on the service index in NSH anddelivers it to WL1 20(1) via interface 34(1). WL1 then acts on incomingpacket 1002.

In the case of FIG. 10, incoming packet 1002 has taken a reduced orsimplified path of SLB→P4→P3→WAF→P3→P2→ZFW→P2→P1→WL1, or reducing theservice chain to bare paths, P4→P3→P2→P1.

By way of further elaboration of communication system 900 of FIG. 9compared to communication system 1000 of FIG. 10, vPath service chainingarchitecture may integrate nodes in either agentful or agentless modes.In agentful mode, a vPath agent is embedded in the service node, whichenables reception and transmission of service path and metadata in-bandwith traffic (packets) being serviced. This is achieved via the vPathservice overlay network.

However, FIGS. 9 and 10 disclose embodiments of agentless service nodes.In agentless mode, because there is no vPath agent, packets are sent andreceived in their native form with no service path and metadatainformation associated with the packets. This is achieved on theunderlay network.

Thus, vPath steers traffic to agentless out-of-path SNs and ensures theservice path and metadata information are preserved so they can beassociated with the traffic when the native traffic servicing iscomplete. However, agentless service nodes that are in-path (such asSLBs 920 and 1020, edge firewalls, and so forth) do not need vPath tosteer traffic to them. Rather, they attract traffic naturally by virtueof their functions. These service nodes may also have extensive internalclassification capability that classifies traffic and performs variousactions on the selected traffic.

Since these service nodes are agentless they cannot communicate servicepath information to the vPath infrastructure. So when traffic exits SLB920 or 1020, for instance, vPath has to reclassify to determine theservice paths in order to put the traffic on the right service chain. Itis difficult, at the infrastructure level, to replicate theclassification performed in a service nodes (the vendors of these twomay be different). Even if the classification can be replicated, it maybe wasteful. So vPath may instead determine service chains at theworkloads. As seen in FIG. 9, this may result in traffic being steeredalong a non-optimal path. However, when traffic is assigned a localidentifier (such as a VLAN) that corresponds to the service chain, SLB1020 can natively direct traffic along the service chain despite beingagentless.

Thus, comparing communication system 900 to communication system 1000,in communication system 900 the service chain is applied at interface34(1), after incoming packet 902 has already traversed interface 34(5),SLB 920, vPath P4, and vPath P1. In contrast, in communication system1000, the service chain is effectively applied at interface 34(5) bymapping it to a local identifier such as a VLAN.

FIG. 11 is a flow chart of a method 1100 performed by a VEM 22 providinghigh-efficiency service chaining, for example at an edge node. Forpurposes of discussion, VEM 22(4) of FIG. 10 is used as an example.

In block 1110, VEM 22 receives traffic, such as packet 1002 of FIG. 10.

In block 1130, VEM 22 correlates an appropriate VLAN to the servicechain. This may be a one-to-one mapping of a specific VLAN to eachindividual service chain, performed by a network administrator inadvance, or it may include identifying a VLAN with a closest-availablepath if one-to-one mapping is not appropriate. Such “fuzzy” mapping matbe appropriate in certain embodiments because even if certain VEMs 22receive packet 1002 extraneously, they will simply forward the packet tothe next node in the chain if they do not have attached to one of theirinterfaces a service node in the service chain. It should also be notedthat VLANs are used by way of non-limiting example only. Any appropriatelocal identifier may be used, for example, forwarding domain identifieror a virtual route forwarding (vrf) domain identifier.

In block 11410, if VEM 22 finds that a service node attached to one ofits interfaces is the next hop in the service chain, VEM 22 forwardspacket 1002 to the service node. For example, in the case of VEM 22(4)of FIG. 10, SLB 1020 is connected to interface 34-4. So VEM 22(4)forwards packet 1002 to SLB 1020 for servicing. SLB 1020 services thepacket according to its ordinary native function, including marking itfor forwarding to the next hop on the VLAN, which may also be the nexthop in the service chain. SLB 1020 then returns packet 1002 to VEM 22(4)via interface 34-4. In block 1150, VEM 22 identifies the service chainand hence the next hop based on the VLAN associated with packet 1002. Inblock 1190, the method is completed and/or the method can be repeated.

Note that in this Specification, references to various features (e.g.,elements, structures, modules, components, steps, operations,characteristics, etc.) included in “one embodiment”, “exampleembodiment”, “an embodiment”, “another embodiment”, “some embodiments”,“various embodiments”, “other embodiments”, “alternative embodiment”,and the like are intended to mean that any such features are included inone or more embodiments of the present disclosure, but may or may notnecessarily be combined in the same embodiments. Note also that an‘application’ as used herein this Specification, can be inclusive of anexecutable file comprising instructions that can be understood andprocessed on a computer, and may further include library modules loadedduring execution, object files, system files, hardware logic, softwarelogic, or any other executable modules.

In example implementations, at least some portions of the activitiesoutlined herein may be implemented in software in, for example, DVS 14.In some embodiments, one or more of these features may be implemented inhardware, provided external to these elements, or consolidated in anyappropriate manner to achieve the intended functionality. The variousnetwork elements (e.g., DVS 14, service controller 16) may includesoftware (or reciprocating software) that can coordinate in order toachieve the operations as outlined herein. In still other embodiments,these elements may include any suitable algorithms, hardware, software,components, modules, interfaces, or objects that facilitate theoperations thereof.

Furthermore, DVS 14 described and shown herein (and/or their associatedstructures) may also include suitable interfaces for receiving,transmitting, and/or otherwise communicating data or information in anetwork environment. Additionally, some of the processors and memoryelements associated with the various nodes may be removed, or otherwiseconsolidated such that a single processor and a single memory elementare responsible for certain activities. In a general sense, thearrangements depicted in the FIGURES may be more logical in theirrepresentations, whereas a physical architecture may include variouspermutations, combinations, and/or hybrids of these elements. It isimperative to note that countless possible design configurations can beused to achieve the operational objectives outlined here. Accordingly,the associated infrastructure has a myriad of substitute arrangements,design choices, device possibilities, hardware configurations, softwareimplementations, equipment options, etc.

In some of example embodiments, one or more memory elements (e.g.,memory element 54) can store data used for the operations describedherein. This includes the memory element being able to storeinstructions (e.g., software, logic, code, etc.) in non-transitorymedia, such that the instructions are executed to carry out theactivities described in this Specification. A processor can execute anytype of instructions associated with the data to achieve the operationsdetailed herein in this Specification. In one example, processors (e.g.,processor 52) could transform an element or an article (e.g., data) fromone state or thing to another state or thing. In another example, theactivities outlined herein may be implemented with fixed logic orprogrammable logic (e.g., software/computer instructions executed by aprocessor) and the elements identified herein could be some type of aprogrammable processor, programmable digital logic (e.g., a fieldprogrammable gate array (FPGA), an erasable programmable read onlymemory (EPROM), an electrically erasable programmable read only memory(EEPROM)), an ASIC that includes digital logic, software, code,electronic instructions, flash memory, optical disks, CD-ROMs, DVD ROMs,magnetic or optical cards, other types of machine-readable mediumssuitable for storing electronic instructions, or any suitablecombination thereof.

These devices may further keep information in any suitable type ofnon-transitory storage medium (e.g., random access memory (RAM), readonly memory (ROM), field programmable gate array (FPGA), erasableprogrammable read only memory (EPROM), electrically erasableprogrammable ROM (EEPROM), etc.), software, hardware, or in any othersuitable component, device, element, or object where appropriate andbased on particular needs. The information being tracked, sent,received, or stored in communication system 10 could be provided in anydatabase, register, table, cache, queue, control list, or storagestructure, based on particular needs and implementations, all of whichcould be referenced in any suitable timeframe. Any of the memory itemsdiscussed herein should be construed as being encompassed within thebroad term ‘memory element.’ Similarly, any of the potential processingelements, modules, and machines described in this Specification shouldbe construed as being encompassed within the broad term ‘processor.’

It is also important to note that the operations and steps describedwith reference to the preceding FIGURES illustrate only some of thepossible scenarios that may be executed by, or within, the system. Someof these operations may be deleted or removed where appropriate, orthese steps may be modified or changed considerably without departingfrom the scope of the discussed concepts. In addition, the timing ofthese operations may be altered considerably and still achieve theresults taught in this disclosure. The preceding operational flows havebeen offered for purposes of example and discussion. Substantialflexibility is provided by the system in that any suitable arrangements,chronologies, configurations, and timing mechanisms may be providedwithout departing from the teachings of the discussed concepts.

Although the present disclosure has been described in detail withreference to particular arrangements and configurations, these exampleconfigurations and arrangements may be changed significantly withoutdeparting from the scope of the present disclosure. For example,although the present disclosure has been described with reference toparticular communication exchanges involving certain network access andprotocols, communication system 10 may be applicable to other exchangesor routing protocols. Moreover, although communication system 10 hasbeen illustrated with reference to particular elements and operationsthat facilitate the communication process, these elements, andoperations may be replaced by any suitable architecture or process thatachieves the intended functionality of communication system 10.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended Claims. In order to assist the UnitedStates Patent and Trademark Office (USPTO) and, additionally, anyreaders of any patent issued on this application in interpreting theClaims appended hereto, Applicant wishes to note that the Applicant: (a)does not intend any of the appended Claims to invoke paragraph six (6)of 35 U.S.C. section 112 as it exists on the date of the filing hereofunless the words “means for” or “step for” are specifically used in theparticular Claims; and (b) does not intend, by any statement in theSpecification, to limit this disclosure in any way that is not otherwisereflected in the appended Claims.

What is claimed is:
 1. A method comprising: receiving a network packeton a network interface; classifying the network packet into a serviceclass; associating the service class with a local identifier; andforwarding the network packet to a path corresponding to the localidentifier.
 2. The method of claim 1, wherein the service class is aservice chain.
 3. The method of claim 1, wherein the local identifier isa virtual local area network (VLAN) identifier.
 4. The method of claim3, wherein associating the service class with a local identifiercomprises associating the VLAN with a service path identifier.
 5. Themethod of claim 1, wherein forwarding the network packet to a pathcorresponding to the local identifier comprises forwarding the networkpacket to a service node configured for applying a service to thenetwork packet.
 6. The method of claim 5, wherein the service is an edgeservice.
 7. The method of claim 5, wherein the service node is anagentless service node.
 8. A network device comprising: an intelligentlycontrolled network interface; and logic, at least partly implemented inhardware, operable for: receiving a network packet on the networkinterface; classifying the network packet into a service class;associating the service class with a local identifier; and forwardingthe network packet to a path corresponding to the local identifier. 9.The network device of claim 8, wherein the service class is a servicechain.
 10. The network device of claim 8, wherein the local identifieris a virtual local area network (VLAN) identifier.
 11. The networkdevice of claim 10, wherein associating the service class with a localidentifier comprises associating the VLAN with a service pathidentifier.
 12. The network device of claim 8, wherein forwarding thenetwork packet comprises forwarding the packet to a service nodeconfigured for providing a service to the network packet.
 13. Thenetwork device of claim 12, wherein the service is an edge service. 14.The network device of claim 12, wherein the service node is an edgeservice node.
 15. One or more non-transitory storage mediums havingstored thereon logic operable for instructing a processor for: receivinga network packet on a network interface; classifying the network packetinto a service class; associating the service class with a localidentifier; and forwarding the network packet to a path corresponding tothe local identifier.
 16. The one or more non-transitory storage mediumsof claim 15, wherein the service class is a service chain.
 17. The oneor more non-transitory storage mediums of claim 15, wherein the localidentifier is a virtual local area network (VLAN) identifier.
 18. Theone or more non-transitory storage mediums of claim 17, whereinassociating the service class with a local identifier comprisesassociating the VLAN with a service path identifier.
 19. The one or morenon-transitory storage mediums of claim 15, wherein forwarding thenetwork packet to a path corresponding to the local identifier comprisesforwarding the network packet to a service node configured for applyinga service to the network packet.
 20. The one or more non-transitorystorage mediums of claim 19, wherein the service is an edge service.